The Third Generation Partnership Project (3GPP) is currently developing the standards for Fifth Generation (5G) systems. It is expected that 5G networks will support many new scenarios and use cases and will be an enabler for the Internet of Things (IoT). It is also expected that 5G systems will provide connectivity for a wide range of new devices such as sensors, smart wearables, vehicles, machines, etc. Flexibility will be a key property in 5G systems. This new flexibility is reflected in the security requirements for network access that mandate the support of alternative authentication methods and different types of credentials other than the usual Authentication and Key Agreement (AKA) credentials pre-provisioned by the operator and securely stored in the Universal Integrated Circuit Card (UICC). More flexible security features would allow factory owners or enterprises to leverage their own identity and credential management systems for authentication and access network security.
Among the new security features in 5G systems is the introduction of a Security Anchor Function (SEAF). The purpose of the SEAF is to cater to the flexibility and dynamicity in the deployment of the 5G core network functions, by providing an anchor in a secure location for key storage. In fact, the SEAF is expected to leverage virtualization to achieve the desired flexibility. As a consequence, the Access and Mobility Management Function (AMF), the 5G function responsible for access and mobility management, can be deployed in a domain that is potentially less secure than the operator's core network, while the master key remains in the SEAF in a secure location.
The SEAF is intended to establish and share a key denoted Kseaf with the user equipment (UE), that is used for deriving other keys, such as the keys for the control plane protection (e.g., Kcn key) and the radio interface protection. These keys generally correspond to the non-access stratum (NAS) keys and the access stratum key (KENB) in Long Term Evolution (LTE) systems. The SEAF is assumed to reside in a secure location and the Kseaf key would never leave the SEAF. The SEAF communicates with the AMFs and provision the necessary key material (derived from the Kseaf key) for the protection of the control plane (CP) and user plane (UP) traffic with the user equipment (UE). One advantage of this approach is that it avoids re-authentication each time a UE moves from an area served by one AMF to an area served by another AMF. In fact, authentication is a costly procedure in particular when the UE is roaming.
Recently, a proposal has been introduced to co-locate the SEAF and AMF, which defeats the purpose of the SEAF in the first place. It is worth noting that the security design in LTE systems was conceptually based on the assumption that the mobility management entity (MME), i.e. the node responsible for mobility management in LTE systems, is always located in a secure location within the operator core network. This assumption does not apply to the AMF in 5G systems. In dense areas, an AMF could be deployed closer to the edge of the network and thus potentially in exposed locations (e.g., in a shopping mall). Therefore, during an AMF change, it is possible that one of the AMFs is not located in an equally secure domain as the other, and therefore the target or the source AMF might need to shield itself from the other.
The Evolved Packet System (EPS) relied on the assumption that the MME is always located in a secure location. Therefore, during an MME change, the new MME simply fetched the security context of the UE from the previous MME. In addition, an MME may optionally trigger a new authentication for forward security.
With legacy mechanisms, forward security (i.e. the old MME does not know the security context used by the new MME) could be achieved via re-authentication but there was no mechanism for backward security (i.e. the new MME does not know the security context used by the old MME). The new AMF may trigger a new authentication thus eliminating any possibility for the old AMF to determine the new keys. The need for re-authentication could, for example, be based on an operator policy taking into account the location of the different AMFs.
Relying solely on the authentication procedure is not very efficient since, performance wise, it is one of the most costly procedures. Therefore, there remains a need to provide security when changing AMFs without the need for re-authentication.